home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1995 March / macformat-022.iso / Shareware City / Graphics / SPD / README.1st < prev    next >
Encoding:
Text File  |  1994-10-28  |  10.2 KB  |  227 lines  |  [TEXT/ttxt]

  1. SPD 3.4 - October 29 1994
  2. -------------------------------
  3.  
  4. by Alexander Enzmann, w/modifications and additions by Eric Haines
  5.  
  6. This is an updated version (a) of the Standard Procedural Databases (SPD v3.1)
  7. package & library code distributed by Eric Haines.  In addition to supporting
  8. the NFF object data format, the file "lib.c" has been extended to support the
  9. input format of the following renderers:
  10.  
  11.     MTV (i.e. NFF)
  12.     POV-Ray 1.0
  13.     POV-Ray 2.0 [subject to change, though]
  14.     Polyray 1.4 to 1.6
  15.     Vivid 2.0
  16.     QRT 1.5
  17.     Rayshade 4.0.6
  18.     RTrace 8.0.0
  19.     Art 2.3 (from Vort)
  20.     RenderMan RIB
  21.     AutoCAD DXF [object data only]
  22.  
  23.     In addition, there is a program nff2rad.c which converts NFF data to
  24. Radiance format (if anyone feels like folding this code into lib.c, please
  25. do).  Note that this converter is not listed in the makefile since it's
  26. special purpose (and standalone, so it's trivial to compile).
  27.  
  28.     There is also an obj2nff.awk awk script which converts Wavefront OBJ
  29. files to NFF format.
  30.  
  31.     A very rudimentary capability to dump polygons in the PLG format used
  32. by REND386 is also supported.  A very simple DXF reader has also been added.
  33. Its primary purpose was to display simple DXF files to the screen, but it has
  34. the side effect of being able to translate DXF files (only 3DFACE, though)
  35. to any of the above ray tracer file formats.
  36.  
  37.     Simple display drivers have been included various flavors for the IBM
  38. PC (VGA, Zortech, Gnu C, etc), Apple Macintosh, and Hewlett Packard Starbase.
  39. Drivers are very simple to write:  you just need a display initialization
  40. routine, a display close routine, and a line drawing routine.  For Unix
  41. systems, for example, just copy and fill in unix.c.
  42.  
  43.     Feel free to play with this stuff in whatever manner you choose.  Eric
  44. was kind enough to make the original freely available, and I'm not about to
  45. change that.  Of course this code is provided without any warranty of any
  46. kind, and no assumption of responsibility for any consequences of using it are
  47. made.
  48.  
  49.  
  50. Changes From Original
  51. ---------------------
  52.  
  53. The biggest changes to the original NFF/SPD stuff is in the area of surface
  54. shading attributes.  Since many raytracers support scale values for more
  55. components of the shading model than are present in NFF, these have been
  56. added.  The new components that have to be given in any call to
  57. "lib_output_color" are:  Ka (ambient), Shine (Phong specular), Shine angle
  58. (50% falloff angle for Phong spot, in degrees).
  59.  
  60. The separation of the Phong values from the Ks (specular) value simply
  61. reflects the fact that most renderers don't force you to do both at the same
  62. time (RTrace being an exception).  Using a falloff angle for the Phong
  63. highlight may seem odd to you, but it really is sensible.  Smaller angles mean
  64. smaller highlights.
  65.  
  66. Another change in the call to "lib_output_color" is a parameter that allows
  67. the definition of a texture name.  Many raytracers support named textures, by
  68. using a non-NULL string, you can specify a predefined texture name (these
  69. things are pretty renderer specific).  All of the examples use NULL, which
  70. defaults to plopping the current color into each primitive.
  71.  
  72.  
  73. Other stuff
  74. -----------
  75.  
  76. The original documents have been included (unchanged).  As far as the
  77. documents for each of the raytracers mentioned above, you will have to get
  78. them from their source.  Most of those raytracers are available on Compuserve
  79. (go GRAPHDEV).  I haven't included one with this library.
  80.  
  81. The database generation programs that were supplied with the original SPD
  82. package have been altered slightly to accept values from the command line.
  83. This makes it a little easier to generate outputs of varying complexity, and
  84. for the various renderers.  Typically the order of the command line options
  85. is:
  86.  
  87.     prog [-s size_factor] [-r renderer] [-c|-t]
  88.  
  89. i.e. "balls -s 2 -r 1 > balls.nff" generates a level 2 sphereflake in MTV's
  90. native format (NFF).  The meaning of "size_factor" varies from program to
  91. program, but basically indicates the complexity of the database that will be
  92. generated.  The "renderer" option corresponds to the definitions in "def.h"
  93. for the various supported renderers.  (i.e. 0 means display on screen, 2
  94. means POV-Ray 1.0, ...)  The [-c|-t] determines the output format, -c means
  95. output curved object primitives, -t means output polygonal patches in a mesh
  96. for curved surfaces.  By default NFF is output, though this is easily changed
  97. by changing OUTPUT_RT_DEFAULT in the code.  Also, typing "prog -?" gives you
  98. the options available.
  99.  
  100. The DXF displayer/converter "showdxf" works as follows:
  101.  
  102.     showdxf [-r renderer] filename
  103.  
  104. "-r 0" means display on screen, the others convert, etc.  Two sample models,
  105. skull.dxf and f117.dxf, are provided as examples.  These were created with the
  106. HyperSpace(tm) 3-D digitizing system from Mira Imaging, Inc.  Contact them at
  107. 801-466-4641 (Seth Jarvis) for more information.
  108.  
  109. I've tried to comment to a reasonable extent, but to be sure, you will need to
  110. be reasonably fluent in "C" to make full use of this stuff.  (Or perhaps make
  111. bindings for Pascal & then just use as a library.)
  112.  
  113. Depending on the features or speed of a particular renderer, you can tell the
  114. library code to output primitives in its native format.  The "sample.c" file
  115. has a simple scene, which can now be output in any supported format.  I have
  116. found this code to be very useful for generating frames for animations from
  117. "C" programs.  All you need to do is open a file for output, generate the
  118. database, and then use a "system" call to perform the render.  There are two
  119. other sample procedural model generation files, "lattice.c" and "shells.c".
  120.  
  121. In addition to the sphere, polygon, and cylinder/cone objects that were
  122. supported in the original SPD, support has been added for:  boxes, tori,
  123. height fields, and superquadrics.  For those raytracers that do not support
  124. these as primitives, the output will be a large number of triangle patches.
  125.  
  126. As far as video output goes, a couple of simple display driver files are
  127. included:  "mac.c", "ibm.c", "hp.c", "disp.c".  These are enough to make
  128. things work, but aren't meant to do much more than that.  If you wish to add a
  129. new display engine for a new machine type not mentioned here, you will need to
  130. create a new file and define the following functions:  display_init,
  131. display_close, display_clear, display_plot [actually, currently not used], and
  132. display_line [which is a little peculiar, see unix.c for details].  There is
  133. also a routine kbhit() for allowing display interrupt from the keyboard, if
  134. needed.  If you don't have access to display drivers for your machine, simply
  135. compile with "unix.c" - all display calls will then be ignored.
  136.  
  137. Oh, yeah - the coordinate system used in this library is left-handed.  This
  138. may seem backwards for those of you used to one renderer vs another, but it is
  139. simple enough to change:  always negate the value of just one of the
  140. coordinates and you get right-handed coordinates.
  141.  
  142. (Try "gears" for a real CPU eater)
  143.  
  144. If you wish to reach the people who tweaked this stuff, we are on Compuserve
  145. (E-Mail, or in the GRAPHDEV forum) as:
  146.  
  147. Alexander Enzmann
  148.   CIS: 70323,2461
  149.   internet: xander@mitre.org
  150.  
  151. Eduard Schwan
  152.   CIS: 71513,2161
  153.   AppleLink: JL.MacTech
  154.   internet: 71513.2161@compuserve.com
  155.  
  156. The original author, Eric Haines, is at erich@eye.com.
  157.  
  158.  
  159. Post-it Notes
  160. -------------
  161.  
  162.    - POV-Ray does not support arbitrary polygons, you get lots of triangles
  163.    - RTrace does not support Phong highlights separately from reflections. It
  164.      is difficult to get RTrace surfaces to look like other renderers
  165.    - Polygons in PLG format will typically need to be scaled way up.
  166.    - Rayshade if compiled right out of the box won't take CR/LF pairs in files,
  167.      end of lines must be a single LF.
  168.    - QRT has bad refraction code and doesn't support arbitrary polygons
  169.    - The Macintosh programs require at least System 6.0.4, and run just
  170.      fine under System 7 & 7.1.  They also need a 68020 CPU, but do not
  171.      require an FPU.  And for some of the larger runs, they may need 2 or
  172.      3 mb of application heap space.  So they should run fine on LCs and
  173.      powerbooks, given enough RAM and disk space!
  174.  
  175. History
  176. --------
  177.  
  178. Sept. 6th release:
  179.   Antonio Costa [acc@asterix.inescn.pt]:
  180.    - Added support for IBM PC DJGPP (GNU C) with GRX graphics [drv_ibm.c]
  181.      and its makefile [makefile.dj] -- requires DJGPP graphic drivers
  182.      *.GRD or *.GRN -- allows high resolutions and is fast!
  183.    - Added EPSILON2 to defs.h because of precision problems (EPSILON is too
  184.      small) and changed lib.c to use EPSILON2.
  185.    - Added my own NFF generator: lattice -- creates a cubic lattice of
  186.      reflective spheres connected by matte cylinders (big CPU eater!)
  187.   Eric Haines [erich@eye.com]:
  188.    - Added shells.c, new procedural database generator (potential CPU eater)
  189.    - Added more PLATFORM_MULTITASK() calls.
  190.    - Added lib_open/lib_close calls (for easier maintenance and extension).
  191.  
  192. Sept. 8th release:
  193.   Antonio Costa [acc@asterix.inescn.pt]:
  194.    - Corrected problem in lib_open/lib_close
  195.    - Corrected filenames for MAC version (*.out) of many generators
  196.    - Changed some things in shells.c (shells_get_opts and light source)
  197.  
  198. Feb 10 1994 release:
  199.   Eduard Schwan [71513.2161@compuserve.com]:
  200.    - Added ReadNFF generator
  201.    - Renamed ShowDXF to ReadDXF, sounded more accurate (ReadOBJ in the works)
  202.    - Broke the giant lib.c file into several smaller libXXX.c files.  The
  203.      Mac Symantec compiler segments code on a per-file basis & lib.c was big
  204.      enough to force an unwanted large-model compile.
  205.    - Added a lib_output_comment routine in libprm.c, which lets you insert
  206.      general comment strings into the data stream in the appropriate dialect.
  207.  
  208. June 1 1994 SPD 3.3f2 release:
  209.    - Added RIB file output
  210.    - Added DXF file output
  211.    - Split lib_get_opts to generator and reader specific command line
  212.      interpreters.
  213.    - More breakup of the lib*.c files to make Mac happy.
  214.  
  215. August 7 1994 SPD 3.3f4 release:
  216.    - Fixed bug in Teapot that stomped the dialog display.
  217.    - Changed code to use standard system palette for screen display, so that
  218.       it no longer goofs up Finder colors upon exit
  219.    - Fixed "In Progress" dialog to refresh if switched out and back in.
  220.  
  221. October 22 1994 SPD 3.3f5 release:
  222.    - Fixed problems in RIB output (updates sent from Eric Haines).
  223.  
  224. October 29 1994 SPD 3.4 release:
  225.    - Final touches, changed version # to 3.4 per Eric's request.
  226.  
  227.